運用中のEC2インスタンスにAuto Healingを設定してみた
こんにちは。AWS事業本部トクヤマシュンです。
運用中のEC2インスタンスにAuto Healingを設定することがありました。
EC2の耐障害性を向上させるはじめの一歩として使うことのできる機会も多いかと思い、今回紹介します。
Auto Healingって何？
Auto Healingとは、Auto Scaling Groupを使って、起動中のEC2インスタンスを常に一定数に保つデザインパターンのことです。
Auto Scaling Groupのヘルスチェック失敗を契機として、インスタンスをサービスから切り離し、新たなインスタンスをサービスインさせることで障害復旧を行います。
Auto Scalingを複数AZで設定しておけば、AZ障害の際も別AZにEC2インスタンスを起動させることができます。
余談ですが、EC2インスタンスの自動復旧の仕組みとして、Auto Recoveryというものもあります。
こちらはEC2のシステムチェック失敗時にEC2の停止→起動を自動で行い、異なる物理ホストで既存インスタンスと同様の設定を持つインスタンスを再起動するものです。
そのため、AZ障害が発生した時にはAuto RecoveryではEC2を再起動させることはできません。
対策を講じたい障害内容に応じて、どのような仕組みを導入するか検討しましょう。
Auto HealingとAuto Recoveryの違いについては以下エントリで分かりやすく解説されていますので、詳しく知りたい方はご参照ください。
なお、オートリカバリーについては2022年3月のアップデートでEC2のデフォルトで有効化されるようになっていますので、意識的に設定する機会は今後減っていくかもしれません。
Auto Healingを設定してみる
ここからは、実際の画面を見ながら、設定方法を確認してみましょう。
ここでは、1台の起動中のEC2を対象として、Auto Healingの設定を下記手順で行います。
- AMI取得
- 起動テンプレート作成
- Auto Scaling Group作成
- 起動中のEC2をAuto Scaling Groupにアタッチ
- Auto Scaling Group設定変更
AMI取得
下記のEC2インスタンスが起動中の状態から始めます。
まずはこのEC2インスタンスのAMIを取得します。
インスタンスを選択→アクションボタン→イメージとテンプレート→イメージを作成と進み、AMIイメージ作成画面に遷移します。
イメージ名を入力し、イメージを作成ボタンをクリックします。
AMI取得時にEC2インスタンスを停止したくない場合は、再起動しないの有効化チェックボックスをONにしてください。
AMIが作成できました。
起動テンプレート作成
作成したAMIを使って起動テンプレートを作ります。
EC2コンソール画面から、起動テンプレート作成画面に遷移します。
起動テンプレート名を入力し、AMIに先ほど作成したAMIを設定します。
設定できたら、起動テンプレートを作成ボタンをクリックします。
最新バージョンが1の起動テンプレートを新規作成できました。
Auto Scaling Group作成
次に、作成した起動テンプレートを使うAuto Saling Groupを作成します。
EC2コンソール画面から、Auto Saling Group作成画面に遷移します。
ステップ1では、Auto Scaling Group名を入力し、起動テンプレートに先ほど作成した起動テンプレートを設定します。
ステップ2では、VPCにEC2が起動しているVPCを指定します。
アベイラビリティゾーンとサブネットには、EC2が起動しているサブネットを設定するのに加えて、他AZが関連付けられた同様の用途を持つサブネットを指定します。
今回の例だと、EC2が起動しているap-northeast-1a内のtest-private-subnet-1aに加え、ap-northeast-1c内のtest-private-subnet-1cを指定しました。
プライマリインスタンスタイプは、起動中のEC2と同じt3.nanoを指定しました。
ステップ3はデフォルトのままとし、ステップ4では下記のグループサイズを設定します。
- 希望する容量:0
- 最小容量:0
- 最大容量:1
こうすることで、Auto Scaling Group作成時にEC2インスタンスが起動しないようにします。
残りのステップ5〜7もデフォルトのまま進み、Auto Scaling Groupを作成します。
この時点ではAuto Scaling Groupに関連づけられているEC2インスタンスは0です。
起動中のEC2をAuto Scaling Groupにアタッチ
EC2インスタンスを選択し、アクション→インスタンスの状態を管理→Auto Scalingグループにアタッチと進み、アタッチ画面に遷移します。
作成したAutoScalingグループを選択し、アタッチボタンをクリックします。
アタッチ完了後、Auto Scaling Groupを確認するとインスタンスがアタッチされていることが確認できます。
また、この時希望する容量も0→1に変更されています。
Auto Scaling Group設定変更
最後に、Auto Scaling Groupの設定変更を行います。
対象のAuto Scaling Groupを選択→編集ボタンをクリックし、編集画面に進みます。
ここでは、最小容量を1に変更し、更新します。
Auto Scaling Groupの希望する容量、最小容量、最大容量の全てを1に設定できました。
以上で起動中のインスタンスのAuto Healingの設定は完了です。
Auto Healing動作を確認してみる
障害をシミュレーションするのは難しいため、インスタンスを手動停止して動作を確認してみます。
インスタンスを選択し、インスタンスの状態→インスタンスを停止と進みます。
停止の確認ポップアップが表示されるので、停止ボタンをクリックします。
しばらく待つと、起動中だったEC2インスタンスは停止され、そのまま終了されます。
その代わりに別のインスタンスが立ち上がり、Auto Healingの動作が確認できました。
今回はたまたまですが、元々のインスタンスとは別のAZで立ち上げることができたこともポイントです。
なお、Nameが空欄ですが、設定したい場合はAuto Scaling Groupの作成時にNameタグの設定を行いましょう。
趣味のスパイスカレー
私の趣味はスパイスカレー作りで、ブログに投稿していってます。
相変わらずAWSには全然関係ありませんが、カレー作りも技術が必要ということで、技術ブログの一環としてお付き合いいただけますと幸いです。
2022.07.14 不覚にも画像貼り忘れていたので、更新しました
- 鰯の梅煮カレー
- キュウリのライタ
- 小松菜のサグ
- キャベツのポリヤル
鰯の梅煮を使った、少し和風なカレーです。
全体としてはカレーの味ですが、後味に残る梅が良いアクセント。
なお、梅干しはスリランカなどではお馴染みのスパイスであるタマリンドペーストの代わりとして、使われることがあります。
意外とカレーにも合うので、オススメです。
最後に
EC2を使ってるけど、耐障害性をあまり意識できていなかったという方は、一度Auto Healingを試してみてはいかがでしょうか。
本エントリーがどなたかのお役に立てば幸いです。
